Architecture for health monitoring systems

ABSTRACT

An architecture allows individual system components to be developed and tested individually, i.e., as distinct modules, and to be subsequently combined through standardized electrical and communication interfaces. Any combination of these modules can be implemented to form different products that provide any number of functions, such as an integrated system for monitoring a health condition and/or delivering a medication. The architecture also provides an approach for dynamically updating the product and offering its users the latest generation of technology even after the users have already purchased the product. In particular, the embodiments employ the communication interfaces to also provide connection to a remote network that can update or upgrade the product&#39;s software when the product is out in the field.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application No.60/932,286, filed May 30, 2007, U.S. Provisional Application No.61/012,721, filed Dec. 10, 2007, and U.S. Provisional No. 61/012,718,filed Dec. 10, 2007, the contents of which are incorporated entirelyherein by reference.

FIELD OF THE INVENTION

The present invention relates generally to a method and system fordeveloping healthcare devices. More specifically, the method and systemof the present invention provides an architecture that allows anycombination of modules with different functions to be easily assembledto form an integrated system for monitoring a health condition and/ordelivering a medication. In addition, the method and system provides anarchitecture that allows the modules to be updated dynamically duringoperation in the field.

BACKGROUND OF THE INVENTION

The quantitative determination of analytes in body fluids is of greatimportance in the diagnoses and maintenance of certain physiologicalconditions. For example, individuals with diabetes frequently check theglucose level in their bodily fluids. The results of such tests can beused to regulate the glucose intake in their diets and/or to determinewhether insulin or other medication needs to be administered.

Diagnostic systems, such as blood-glucose systems, may employ a meter orinstrument to calculate the glucose value in a blood sample from anindividual. Such instruments operate by measuring an output, such ascurrent or color, from a reaction with the glucose in the sample. Thetest results typically are displayed and stored by the meter. Basicsystems allow the user to access the test results directly from themeter via a keypad or other interactive component.

Other diagnostic systems, however, provide more advanced functionalityto allow a user to process and manage test results. For example, somesystems allow a user to load test results from a blood-glucose meteronto a processing device, such as a conventional desktop personalcomputer (PC), and to process and display the results with adata-management application. However, using the processing power of PCtechnology to organize results from a blood-glucose meter is just oneexample of how diagnostic systems provide more functionality byincorporating different technologies into a diagnostic process.

Although integrating different technologies and functions may yieldhighly sophisticated and extremely useful diagnostic systems, theintroduction of such systems into the marketplace is slowed by currentapproaches to product design and development in the industry. Forexample, current approaches to the design of multi-function productsemploy complicated system architectures that interconnect the variety offunctional elements via distinct and non-standard techniques.Accordingly, a functional element must be developed with the specificfinal product and the other functional elements in mind. In other words,the complex architecture results in dependencies between functionalelements, and thus does not allow each element to be developedindependently and/or in parallel. As such, the development processrequires more time as more components are added and complexity isincreased.

In addition, although the final integrated product may provide thefeatures and advantages of a variety of technologies, the rapid pace ofchange in these technologies may outdate the final product before thefinal product is introduced to the market, particularly because productdevelopment takes such a long time. In other words, current approachesto product development make it difficult to ensure that the users of theproduct have the latest generation of technology. Where the cost ofintegrated products may be relatively high due to the greater amount offunctionality, consumers may find less justification in purchasing suchproducts when their technology may become quickly outdated.

In view of the foregoing, there is a need for design and developmentapproaches that simplify the process of combining differenttechnological components into a single product while meeting the highquality standards for medical devices. In particular, there is a needfor an approach that simplifies interfaces between components andtherefore permits different combinations of components to be easily andreliably integrated regardless of the number of components. Moreover,there is a need for an approach that allows the final product to bedynamically and continuously updated to offer its users the most currenttechnology.

SUMMARY OF THE INVENTION

The embodiments described herein address the needs identified above byproviding an architecture that allows individual system components to bedeveloped and tested individually, i.e., as distinct modules, and to besubsequently combined through standardized electrical and communicationinterfaces. Any combination of these modules can be implemented to formdifferent products that provide any number of functions, such as anintegrated system for monitoring a health condition and/or delivering amedication.

Although the architecture makes it more feasible to shorten a product'sdevelopment cycle and to introduce the product to consumers morequickly, the embodiments also provide an approach for dynamicallyupdating the product and offering its users the latest generation oftechnology even after the users have already purchased the product. Inparticular, the embodiments employ the communication interfaces to alsoprovide connection to a remote network that can update or upgrade theproduct's software when the product is out in the field. This process isknown as a field upgrade.

Because the interfaces and communication protocols are designed tofacilitate connection between different components and the rest of thesystem, the embodiments also provide functionality that ensures thatunauthorized individuals or devices cannot connect with the system andcompromise the security of data, such as personal medical information,which may be collected, stored, and handled by the system. With thisunderlying security functionality, particular technologies, such aswireless communication, can be implemented as components of medicaldiagnostic systems without concern over unauthorized access to personalinformation.

In addition, due to the important medical functions associated with theassembled product, embodiments employ validation procedures to ensurethat any data transferred to the product, for example, during fieldupgrade, does not corrupt the data or the software stored by the productand that the product continues to operate as expected.

Still other aspects, features, and advantages of the present inventionare readily apparent from the following detailed description, byillustrating a number of exemplary embodiments and implementations,including the best mode contemplated for carrying out the presentinvention. The present invention is also capable of other and differentembodiments, and its several details can be modified in variousrespects, all without departing from the spirit and scope of the presentinvention. Accordingly, the drawings and descriptions are to be regardedas illustrative in nature, and not as restrictive. The invention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates a diagram of an architecture according to aspects ofthe present invention.

FIG. 1B illustrates a diagram of another architecture according toaspects of the present invention.

FIG. 2A illustrates an example security measure that can be employed byan architecture according to aspects of the present invention.

FIG. 2B illustrates another example security measure that can beemployed by an architecture according to aspects of the presentinvention.

FIG. 2C illustrates a further example security measure that can beemployed by an architecture according to aspects of the presentinvention.

FIG. 2D illustrates yet another example security measure that can beemployed by an architecture according to aspects of the presentinvention.

FIG. 3 illustrates an example diabetes-management system employing anarchitecture according to aspects of the present invention.

FIG. 4 illustrates another diagram of an architecture according toaspects of the present invention.

FIG. 5 illustrates an example of a diagnostic system employing anarchitecture according to aspects of the present invention.

FIG. 6 illustrates another example of a diagnostic system employing anarchitecture according to aspects of the present invention.

FIG. 7 illustrates yet another example of a diagnostic system employingan architecture according to aspects of the present invention.

FIG. 8 illustrates a field-upgradeable architecture according to aspectsof the present invention.

FIG. 9 illustrates an example for employing a field upgrade according toaspects of the present invention.

DESCRIPTION OF ILLUSTRATED EMBODIMENTS

The embodiments described herein provide a system architecture thatallows individual system components, or modules, to be developed andvalidated independently (as distinct modules) and subsequently combinedthrough standardized electrical and communication interfaces. Thestandardized interfaces facilitate the combination and configuration ofthese modules to form different products that provide any number offunctions. While the architecture can be used to form a fixedcombination of components, the approach also permits reconfigurable orexpandable combinations where different components may be easily removedor added to the system. In addition, as described further below, thearchitecture provides an approach for dynamically updating the modulesafter they have been integrated into the product.

FIG. 1A illustrates a conceptual diagram of a modular architectureaccording to aspects of the present invention. As shown in FIG. 1A, amodular architecture system 1 includes central engine 10 that isconnected to a plurality of modules 30A, 30B, 30C, and 30D, each ofwhich provides a functionality for a health monitoring and deliverysystem. The central engine 10 enables the modules 30A, 30B, 30C, and 30Dto work as an effective system. For example, the central engine 10allows information to be communicated between the modules 30A, 30B, 30C,and 30D. For example, module 30D may be a computing device with softwarethat processes data received from the other modules 30A, 30B, and 30Cvia the central engine 10. As FIG. 1A further illustrates, interfaceelements 22A, 22B, 22C, and 22D of the central engine 10 connect withrespective interface elements 24A, 24B, 24C, and 24D to establishcommunications between the central engine 10 and the modules 30A, 30B,30C, and 30D. The interfaces may provide wired, i.e. physical, and/orwireless communications. Advantageously, the centralized organization ofthe interface architecture facilitates the integration of modules 30A,30B, 30C, and 30D, which can be developed and tested separately fromeach other. Moreover, although the interface elements 22A, 22B, 22C, and22D of the central engine 10 do not have to follow the samecommunications protocol, the interface elements 22A, 22B, 22C, and 22Dcan employ the most widely-used standard protocols so that the centralengine 10 is more likely to be compatible with a given module.

Although the modules 30A, 30B, 30C, and 30D of FIG. 1A may allcommunicate information with each other, it is contemplated that amodule connected to the central engine 10 does not have to communicatewith all of the other modules. Indeed, a module may be communicativelyisolated from any, including all, of the other modules. For example, thenature of data and/or software on a particular module may be highlysensitive, so the module may be isolated from the other modules toenhance the security and/or integrity of the data.

In one embodiment, the central engine 10 is implemented on a motherboard, while each module is separately implemented on a daughter board.The daughter boards are standardized so that they may connect to asingle mother board to be integrated with the system. In other words,specific interfaces with boards corresponding to other modules do nothave to be developed each time a new module is implemented. Due to thisstandardized approach, using commercial off-the-shelf (COTS) hardwarefor the mother and daughter boards becomes more feasible.Advantageously, using COTS hardware requires less development time thanan application-specific integrated circuit (ASIC) approach.

In some embodiments, the mother board and the daughter boards mayphysically reside on separate circuit boards. In other embodiments, themother board and the daughter boards may all be physically integratedonto the same circuit board. In further embodiments, the mother boardand a combination of daughter boards may be physically integrated ontothe same circuit board, while other daughter boards reside on separatecircuit boards. Moreover, in some embodiments, the mother board and thedaughter boards, whether on the same circuit boards or not, may all bedisposed in the same housing, or casing. Meanwhile, in otherembodiments, some or all of the daughter boards may be disposed in oneor more housings separate from the mother board's housing. In general,the components of embodiments may be subject to varying degrees ofphysical integration regarding assembly on different circuit boards orwithin different housings, etc. To accommodate this variation inphysical configuration, more than one interface type may be required toconnect the daughter boards to the mother board, but as discussedpreviously, the interfaces between the central engine and the modules donot have to follow the same communications protocol. The interfaceelements associated with the mother board can employ the mostwidely-used standard protocols so that the central engine is more likelyto be compatible with a given module.

The centralized architecture using standardized interfaces facilitatesthe development of compatible modules. When adding functionality to thesystem, integration with the architecture is easily achieved byemploying a compatible interface element. Moreover, the new module canbe developed independently of the other modules, because only a singleinterface with the central engine 10 is required. In other words, evenif the new module must communicate with other modules in the system, thenew module does not have to be designed for a direct connection with theother modules, so the communications configuration of the other modulesis not a significant design consideration for the new module.Accordingly, the ability to independently develop additional modulesthat easily connect with the central engine 10 enables systems employingthis architecture to be flexible and reconfigurable. For example, such asystem can be expanded with new modules or upgraded with new versions ofexisting modules.

Although FIG. 1A illustrates an embodiment with the single centralengine 10 connected to modules 30A, 30B, 30C, and 30D, the centralengine 10 in some embodiments may also connect to a secondary centralengine 40 as illustrated in FIG. 1B. As shown in FIG. 1B, the centralengine 10 is connected to modules 30A, 30B, and 30C via correspondinginterface elements 22A/24A, 22B/24B, and 22C/24C. Meanwhile, the centralengine 40 is connected to modules 60A, 60B, and 60C via correspondinginterface elements 52A/54A, 52B/54B, and 52C/54C. As with the modules30A, 30B, and 30C, the modules 60A, 60B, and 60C may be developedindependently of the other modules according to a modular architecturethat only requires a single interface with the central engine 40. Asfurther illustrated in FIG. 1B, the central engine 10 may be connectedto the central engine 40 via interface elements 22D and 52D. Like theother interface elements, the interface elements 22D and 52D may providewired, i.e. physical, or wireless communications. In some embodiments,the central engine 10 assumes a host function for the central engine 40.For example, if the central engine 10 connects to the central engine 40according to universal serial bus (USB) communication protocol, standardUSB requires a host-slave relationship between the two systems.

In the embodiment of FIG. 1B, the central engine 10 may access thefunctionalities provided by the modules 60A, 60B, and 60C, andconversely, the central engine 40 may access the functionalitiesprovided by the modules 30A, 30B, and 30C. Even though the resultingcombination may function like a single central engine connected to allsix modules 30A, 30B, 30C, 60A, 60B, and 60C, the central engines 10 and40 may be developed separately. As such, the development of a set ofmodules can be advantageously organized into separate subsets. Forexample, medical diagnostic systems may include critical medicaldevices, such as a blood-glucose meter, as well as other types ofdevices, such as a heart rate monitor. The critical medical devices mayrequire very rigorous product validation during development and may besubject to government regulations. Meanwhile, the other types of devicesmay not require the same type or same level of validation. As such,modules involving critical medical devices may have very differenttimelines and guidelines for product development compared to the othertypes of health care devices. Thus, in this case, it may be advantageousto organize the modules into two product development groups. Inaddition, every time a product involving critical medical devices isredeveloped or updated to include new features, government regulationsmay require revalidation of the product even if the new features may berelatively minor. For example, if a heart rate monitor is added to acentral engine that is already connected to a blood-glucose meter, theentire system may have to be revalidated at great cost and effort, eventhough the new modules is a less critical health care device. However,the central engine connected to the blood-glucose meter can remainunchanged if the central engine already has the capability to connect toa secondary central engine that in turn is connected to the heart ratemonitor. In other words, deploying new modules involving other healthcare devices and other features through the secondary central engineprovides a way to expand the overall product without changing thearchitecture associated with the primary central engine. Moreover, anyvalidation of the architecture associated with the secondary centralengine may be conducted without affecting the architecture associatedwith the primary central engine.

Although an advantage of the architectures described herein is the easeby which new modules can interface with the system and establishcommunications and data exchange, issues relating to the security ofpersonal medical data have discouraged using highly compatiblecommunication technologies with medical devices, such as personaltesting devices that measure and store health data. To address theseissues, embodiments according to aspects of the present inventionprovide functionality that helps to ensure that unauthorized individualsor devices cannot connect with the system and compromise the security ofany personal medical information. The central engine 10 may beresponsible for providing security measures. Alternatively oradditionally, a component or module with special security functions maybe employed to promote system security. With such securityfunctionality, particular technologies, such as wireless communication,can be implemented as components of medical diagnostic systems withoutheightened concern over unauthorized access to personal information.

FIGS. 2A-D illustrate examples of security techniques that may beemployed by an architecture according to aspects of the presentinvention. As shown in FIG. 2A, the central engine 10 may prompt theuser for a user ID and password, personal identification number (PIN),or other authentication information, when a module 30 attempts tointerface with the central engine 10 or to access data through thesystem. The module 30 is only allowed connection or data access if theresponse to the security prompt corresponds with authenticationinformation stored at the system. For example, the module 30 may be a PCexecuting a data-management program that uploads test data from ablood-glucose meter connected to the central engine 10. When the programattempts to communicate through an interface connection or tries toaccess data, the user must submit a user ID and password. Theauthentication information may be entered through a user interface, e.g.a keypad or keyboard, on the PC or the central engine 10. If the module30 is used frequently to access data through the central engine 10, theuser may find it inconvenient to enter authentication informationrepeatedly. Thus, some embodiments may allow a user to set a time period(from zero to infinity) between authentications from the particularmodule 30. The central engine 10 records a unique identifier, e.g.device ID, for module 30 to keep track of the time period. For instance,a security prompt may be required if the specified time, e.g. one day,has passed since the last authentication. Alternatively, the user maystop all further security prompts from occurring after the firstauthentication. In this alternative case, the first authentication actsas a registration with the central engine 10 to permit all future accessfrom the module 30.

As shown in FIG. 2B, a unique identifier, e.g. device ID, for module 30may be registered with the central engine 10. This unique identifier maybe entered by the user or recorded when the authentication process shownin FIG. 2A is completed for the first time. Alternatively, registrationof the module 30 may be achieved through an initial, e.g. factory,set-up process. In this alternative case, registration of additionalmodules may be prohibited after the initial set-up, thereby fixing thenumber of modules in the system. When the module 30 subsequentlyattempts to connect or access data, the central engine 10 automaticallyrecognizes the module 30 and permits access.

In the embodiments of FIGS. 2A and 2B, the module 30 is authenticated orregistered in a one-way process. In other words, the central engine 10is not required to be authenticated or registered with the module 30. Incontrast, as shown in FIG. 2C, both the central engine 10 and the module30 are required to be registered with each other. Matching of uniqueidentifiers for the pair is required before any communication takesplace between the central engine 10 and the module 30. This pairmatching is particularly applicable to wireless communication betweentwo devices. The process prevents intentional unauthorized access, andalso prevents interference between two different systems. For example,if a user is in a setting, such as a hospital or clinic, where othersare using similar wireless analyte-testing devices, such asblood-glucose meters, pair matching prevents another person'sblood-glucose meter from accidentally communicating with the user'sdiagnostic system and providing the wrong data.

Data security may also be enhanced by using encrypted data duringcommunications, as shown in FIG. 2D. This is also particularlyapplicable to wireless communications, so that any intercepted data willbe unreadable. The data encryption may be achieved by using privateencryption keys.

Data security may be further enhanced by ensuring that all data isstored by the central engine 10 within memory in the architecture and isnot transferred to any connected modules. Thus, a user may, for example,use a public computer to interface with the system and no data will betransferred to the public computer for others to access.

FIG. 3 provides a non-limiting example of a diabetes-management system100 that can be formed from the architecture approach described herein.The diabetes-management system 100 is advantageous to those individualswho are actively involved in monitoring and recording measurements oftheir blood glucose concentrations and/or other analytes of interest.

As shown in FIG. 3, the diabetes-management system 100 includes ablood-glucose meter (BGM) 310, a continuous glucose monitoring (CGM)module 320, an insulin-delivery device 330, and a computing device 370,which may include diabetes data management software 375. The modules310, 320, 330, and 370 are combined, as described further below, usingthe architecture approaches described herein to provide healthmonitoring and delivery functions for the diabetes-management system100. In particular, the BGM 310 provides point-in-time measurements ofblood-glucose concentrations in blood samples; the CGM module 320provides continuous measurements of blood-glucose concentration; and theinsulin-delivery device 330 delivers insulin to the user.

In addition, the computing device 370 executes the software 375 toreceive data from the modules 310, 320, and 330 and provides advanceddata processing and management capabilities. The computing device 370may be selected from a variety of processing devices, such as desktop orlaptop personal computers (PCs), handheld or pocket personal computers(HPCs), compatible personal digital assistants (PDAs), and smartcellular phones. The processing devices may employ a variety ofoperating systems and configurations. For example, if the computingdevice 370 is a desktop or laptop personal computer, the operatingsystem may be a version of Microsoft® Windows®. Alternatively, if thecomputing device 370 is a PDA, the operating system may correspond withthose of PALM® handhelds from Palm, Inc., or Blackberry® devices fromResearch in Motion Limited. In general, computing device 370 includes aprocessor that is capable of receiving and executing any number ofprogrammed instructions.

The data-management software 375 on the computing device 370 may be acollection of programs or computer code that receives and processes datameasured by the modules 310 and 320, for example. The software 375processes and/or displays this input in a manner that is desired by theuser. This information may be used by, for example, a user, home careprovider (HCP), and/or a physician. The measured data from the modules310 and 320 may include, for example, the concentration of glucoseand/or other analytes in a person's blood or other bodily fluid.Advantageously, the software 375 can provide the advanced displays anddata processing that may be required by a user who tests multiple timesa day (e.g., about six to about ten times a day). For example, thesoftware 375 may include a product similar to WINGLUCOFACTS® DiabetesManagement Software available from Bayer HealthCare LLC (Tarrytown,N.Y.). As such, the software 375 may provide a complete tool kit thatreceives and stores test results from a blood-glucose measurementsystem, receives and stores other testing information such as test timesand meal markers, tracks test results in an electronic logbook,calculates averages and provides statistical analysis of outlier testresults, summarizes and provides feedback on the test results, providesa customizable graphical user interface, displays user-friendly chartsand graphs of the test results, tracks test results againstuser-specific target ranges, provides predictive analysis, and/or sendsdata to healthcare professionals via fax, email, etc. As describedpreviously, data security is enhanced if the software 375 does notupload data from the modules 310 and 320 to the computing device 370 andthe data is always stored within a single central storage device.

As described further below, the use of software or programmedinstructions is not limited to the computing device 370. Moreover, theuse of embodiments of the present invention are not using the particularmodules 310, 320, 330, and 370. FIG. 4 illustrates a broader systemdiagram with other modules 300. For instance, as FIG. 4 illustrates, anA1_(C) module 340, which monitors glucose control over time, may also beused in a diabetes-management system. The modules 300 also include otherhealth monitor modules 350, such as blood pressure and heart ratemonitors. Indeed, modules 300 may measure and/or record health data thatdo not require analyte testing, such as temperature measurements, bloodpressure measurements, heart rate measurements, breathing measurementsfor chronic obstructive pulmonary disease (COPD) analysis, weightmeasurements for analyzing Lasix use, and the like. In further systems,other utility device modules 360 may include training modules,connectivity modules providing further connection to other systems, andother modules that improve or enhance a user's experience with thesystem. For example, it is contemplated that entertainment or mediamodules such as game modules or music player modules may be combinedwith the systems described herein. Providing entertainment features, forexample, may encourage patients, particularly young patients, to keepthe diagnostic systems with them wherever they go, so that healthconditions, such as diabetes, can be monitored regularly. Furthermore,in some systems, the architecture may also employ open source code sothat additional custom or specialized modules may be developed by usersor third parties for integration with the architecture described herein.Accordingly, an endless variety of modules providing any type offunctionality may be employed.

As shown in FIG. 3, the system 100 includes a central engine 110, suchas a digital engine, for the architecture and enables the modules 300 tobe easily and effectively combined. For example, the central engine 110,the BGM 310, the CGM module 320, and the insulin-delivery device 330 canbe effectively combined to create an artificial pancreas. Alternatively,the central engine 110, the BGM 310, and the CGM 320 can be combined toform a CGM with an embedded BGM unit. Or as a further example, thecentral engine 110, the BGM 310, and the insulin-delivery device 330 canbe combined to form a pump controller with an embedded BGM unit.

Referring again to FIG. 4, the central engine 110 may include aprocessor 112 and a power management element 114. The processor 112 iscapable of receiving and executing any number of programmedinstructions, and may be a microcontroller, microprocessor, digitalsignal processor, or the like. The programmed instructions to beexecuted by the processor 112 may be embedded or may be retrievable froma storage device 250, a connected module 300, or another source such asan Internet website. The processor 112 centrally manages communicationswith the modules 300. In some cases, the processor 112 may also executesoftware that handles the operation of some modules 300. Moreover, theprocessor 112 may give the modules 300 access to common resources orfeatures such as the user interfaces 220 described further below.

Power management element 120 distributes power from a power supply tothe processor 112 as well as modules 300 that do not have their ownpower source. The power management system 114, for example, may beconfigured to enter a standby mode to minimize power use when the systemis idle. Additionally, if a rechargeable battery is employed, the powermanagement system 114 may also handle the recharging of the battery.

As also shown in FIG. 4, the central engine 110 is connected toinput/output interfaces 200, which can be divided into two differentcategories: communication interfaces 210 and user interfaces 220. Thecommunication interfaces 210 govern the exchange of data between thecentral engine 110 and the modules 300. In general, the communicationinterfaces 210 can accommodate wired and/or wireless communications.Wired communications include, for example, communications by universalserial bus (USB) connection. Wireless communications include, forexample, radio-frequency (RF) links (e.g., a short-range RF telemetry),infrared (IR) links, and/or Wi-Fi. Some known RF technologies, forexample, include Bluetooth® wireless technologies, Zigbee, Z-Sense™technology, FitSense, and BodyLAN™ system. It is understood that othercommunication technologies, or protocols, may be employed.

Referring again to FIG. 3, a wired, or physical, connection 212 existsbetween the central engine 110 and the computing device 370 while awireless connection 214 exists between the central engine 110 and eachof the CGM module 320 and the insulin-delivery device 330. It is notedthat the BGM 310 is assembled with the central engine 110 in the housing101. As such, the interface between the central engine 110 and the BGM310 involves a wired connection (not shown). Indeed, as FIG. 3illustrates, the modules 300 may be combined in any suitable arrangementin relation to the central engine 110 and to other modules 300. Like theBGM 310, some modules 300 may be assembled with the central engine 110within the same housing, while other modules 300 may be provided inseparate housings and arranged remotely from the central engine 110. Itis also contemplated that in addition to other configurations describedherein, some modules 300, having the form of circuit components, forexample, may be assembled on the same printed circuit board assembly(PCBA) as circuit components for the central engine 110 with a circuitconnection providing the interface 210.

FIG. 5 illustrates a further example of a connection between the centralengine 110 and a module 300, namely the BGM 310. Unlike FIG. 3, the BGM310 of FIG. 5 is not disposed in a housing 101 with the central engine110, but the description provided with reference to FIG. 5 is equallyapplicable to the configuration in FIG. 3.

Referring to FIG. 5, the BGM 310 with a test sensor 316 is illustrated.The test sensor 316 is configured to receive a fluid sample which isanalyzed using the BGM 310. Analytes that may be analyzed includeglucose, lipid profiles (e.g., cholesterol, triglycerides, LDL and HDL),microalbumin, hemoglobin A1_(C) fructose, lactate, or bilirubin. It iscontemplated that other analyte information may be determined (e.g.,analyte concentrations). The analytes may be in, for example, a wholeblood sample, a blood serum sample, a blood plasma sample, other bodyfluids like ISF (interstitial fluid) and urine, and non-body fluids.

The test sensor 316 includes a fluid-receiving area for receiving asample of body fluid. For example, a user may employ a lancet or alancing device to pierce a finger or other area of the body to producethe blood sample at the skin surface. The user may then collect thisblood sample by placing the test sensor 316 into contact with thesample. The fluid-receiving area may contain a reagent which reacts withthe sample to indicate the concentration of an analyte in the sample.

The test sensor 316 may be an electrochemical test sensor. Anelectrochemical test sensor typically includes a plurality of electrodesand a fluid-receiving area that contains an enzyme. The fluid-receivingarea includes a reagent for converting an analyte of interest (e.g.,glucose) in a fluid sample (e.g., blood) into a chemical species that iselectrochemically measurable, in terms of the electrical current itproduces, by the components of the electrode pattern. The reagenttypically contains an enzyme such as, for example, glucose oxidase,which reacts with the analyte and with an electron acceptor such as aferricyanide salt to produce an electrochemically measurable speciesthat can be detected by the electrodes. It is contemplated that otherenzymes may be used to react with glucose such as glucose dehydrogenase.In general, the enzyme is selected to react with the desired analyte oranalytes to be tested so as to assist in determining an informationrelated to an analyte (e.g. analyte concentration) of a fluid sample. Ifthe concentration of another analyte is to be determined, an appropriateenzyme is selected to react with the analyte.

Alternatively, the test sensor 316 may be an optical test sensor.Optical test sensor systems may use techniques such as, for example,transmission spectroscopy, diffuse reflectance, or fluorescencespectroscopy for measuring the analyte concentration. An indicatorreagent system and an analyte in a sample of body fluid are reacted toproduce a chromatic reaction, as the reaction between the reagent andanalyte causes the sample to change color. The degree of color change isindicative of the analyte concentration in the body fluid. The colorchange of the sample is evaluated to measure the absorbance level of thetransmitted light.

Some commercially available test sensors that may be used by theembodiments described herein include those that are availablecommercially from Bayer HealthCare LLC (Tarrytown, N.Y.). These testsensors include, but are not limited to, those used in the Ascensia®CONTOUR® blood glucose monitoring system, the Ascensia® BREEZE® andBREEZE®2 blood glucose monitoring system, and the Ascensia® Elite® andElite® XL blood glucose monitoring system. It is contemplated that othertest sensors, in addition to the ones listed above, may be incorporatedinto the methods and systems of the present invention.

As illustrated in FIG. 5, the BGM 310 receives and engages the testsensor 316. The BGM 310 includes a reaction-detection system formeasuring the concentration of analyte for the sample collected by thetest sensor 316. For example, the reaction-detection system may includecontacts for the electrodes to detect the electrochemical reaction foran electrochemical test sensor. Alternatively, the reaction-detectionsystem may include an optical detector to detect the chromatic reactionfor an optical test sensor. To calculate the actual concentration ofanalyte from the electrochemical or chromatic reaction measured by thereaction-detection system and to generally control the procedure fortesting the sample, the BGM 310 employs at least one processor 312,which may execute programmed instructions according to a measurementalgorithm. Data processed by the processor 312 may be stored in a memory313. Furthermore, the BGM 310 may have a user interface 315 thatincludes a display, which, for example, may be a liquid-crystal display.Pushbuttons, a scroll wheel, touch screens, or any combination thereof,may also be provided as a part of the user interface 315 to allow a userto interact with the BGM 310. The display typically shows informationregarding the test results, the testing procedure and/or information inresponse to signals input by the user.

Although the BGM 310 can store test results and provide a user interface315 to display test results, the data-management software 375 on thecomputing device 400 provides more advanced functionality for managing,processing, and displaying test results and related information.Therefore, the test-related data collected by the BGM 310 can becommunicated via the central engine 110 to the computing device 370 foruse with the data-management software 375. As shown in FIG. 5, the BGM310 includes a BGM interface element 311 that enables the BGM 310 toconnect with the central engine 110 via the engine interface element111. Furthermore, the central engine 110 is connected to the engineinterface element 116 which in turn is connected to computer interfaceelement 376 of computing device 370. The BGM interface element 311, thecomputer interface element 376, and the engine interface elements 111and 116 may employ the interface technologies described above to makethe devices compatible and enable the appropriate data connections. Forexample, engine interface 111 and BGM interface 311 may connect viaBluetooth® wireless, while the engine interface 111 may connect to thecomputer interface 376 through a connection to a USB port. Thus, it isreadily seen that although the BGM 310 and the computing device 370 maynot have compatible interfaces, the architecture of FIG. 5 enables datato be exchanged between them. Moreover, it is also readily contemplatedthat the development of the BGM 310 can be accomplished without regardto direct compatibility with USB interface of the computing device 370.

As discussed previously, the central engine 110 has the power management114 which may include a power supply that is rechargeable via theconnection with the computing device 370 or some other power source.When the central engine 110 and the BGM 310 are connected, arechargeable battery can be recharged via power management 314.

As described previously, the BGM 310 in FIG. 5 employs at least oneprocessor 312, which may execute programmed instructions. Moreover, theBGM 310 may have a user interface 315, which includes a display topresent information to the user, as well as pushbuttons, a scroll wheel,touch screens, or any combination thereof to enable interaction by theuser. With such components, the BGM 310 generally controls the wholeprocedure for testing the sample and calculates the test results.Indeed, the description provided with reference to FIG. 5 generallyexplains how the test results already calculated by the BGM 310 may besubsequently shared with other modules such as the computing device 370.However, it is contemplated that the processor 112 of the central engine110 can also provide a wider range of functions. In fact, it is furthercontemplated that the processing in a health monitoring and deliverysystem can be distributed among the components, including the centralengine 110, in varying manners.

For example, FIG. 6 illustrates a sensor-receiving module 380 thatrequires other components to handle substantially all of the processing.Like the BGM 310, the sensor-receiving module 380 is configured toreceive a test sensor 316. However, the sensor-receiving module 380 doesnot have a processor to manage the testing procedure or to calculatetest results. In addition, the sensor-receiving module 380 has no userinterface to communicate with the user. In general, the sensor-receivingmodule 380 is designed to merely receive a test sensor 316 and toprovide an interface element 381 for physical connection to the rest ofthe diagnostic system. As a result, analysis of the test sample on thetest sensor 316 is only possible when the sensor-receiving module 380connects with a device that has a processor to analyze the sample viathe interface element 381.

As shown in FIG. 6, the interface element 381 of the sensor-receivingmodule 380 is connected to the interface element 111, which in turn isconnected to the digital sensor 110. It is noted that the connectionbetween the sensor-receiving module 380 and the central engine 110 mayrequire a host function, such as the USB host function, to be employedby the central engine 110. In one embodiment, the digital sensor 110 isalso connected to the interface element 376 of the computing device 370.The interfaces between the sensor-receiving module 380, the centralengine 110, and the computing device 370 may employ any of the interfacetechnologies, such as USB or Bluetooth® technology, described above.Accordingly, the computing device 370 can execute software 377 tocontrol the procedure for testing a sample and calculating the testresults in a manner similar to the processor 312 on BGM 310 in FIG. 5.In operation, the sensor-receiving module 380, the central engine 110,and the computing device 370 are connected as shown in FIG. 6. The testsensor 316 is used to collect a fluid sample, such as a blood sample.If, for example, the test sensor 316 is an electrochemical test sensor,the sensor-receiving module 380 system may include electrical contactsto receive the electrical signal from the electrochemical reaction thatoccurs between the sample and the reagent on the test sensor 316. Theconnection between the sensor-receiving element 380 and the centralengine 110 is connected to the circuit containing the electrical sensorsso that the central engine 110 receives the electrical signal from theelectrochemical reaction. This signal can then be passed to thecomputing device 370 to process the signal and determine the testresults using a measurement algorithm. The user interface on thecomputing device 370 can be used to display the test results or toreceive instructions from the user.

It is understood that other techniques may be employed to communicate asignal from the sensor-receiving module 380. For example, a test sensor316 may be an optical test sensor and the sensor-receiving system 380may include an optical detector to detect a chromatic reaction. If thesensor-receiving module 380 requires any power to receive or process asignal from the test sensor 316, the power can be drawn through itsconnection with the central engine 110.

Alternatively, in another embodiment, the computing device 370 is notemployed in the system, so that the sensor-receiving module 380 is onlyconnected to the central engine 110 as shown in FIG. 7. As such, thetest result calculations are completed by the processor 112 of thecentral engine 110 and the test results are displayed on a userinterface connected to the central engine 110. As shown in FIG. 7, auser interface 115 may be incorporated into the housing 101.

The measurement software 253 for controlling the test process anddetermining the results may be available through the storage device 250as illustrated in FIG. 7. As illustrated in FIG. 4, the storage device250 corresponds with another type of input/output interface 200. Thestorage device 250 may be a flash memory device, such as a universalserial bus (USB) flash drive or a memory card. USB flash drives are alsoknown as thumb drives, handy drives, flash sticks, or jump drives.Memory cards may have a variety of formats, including PC Card (PCMCIA),CompactFlash (CF), SmartMedia (SM/SMC), Memory Stick (MS), MultimediaCard (MMC), Secure Digital Card (SD), xD-Picture Card (xD), IntelligentStick (iStick), ExpressCard, or some variation thereof. Flash memorydevices may employ non-volatile memory so that the software associatedwith the measurement software 253 may be retained in the storage device250 even when the storage device 250 receives no power. In someembodiments, the memory in the storage device 250 may includeexecute-in-place (XIP) memory, such as NOR flash memory, so that themeasurement software 253 stored on the memory can be executed directly.It is also contemplated that the storage device 250 may employ otherstorage media, such as floppy disk or optical disc (CD, DVD, Blu-raydisc).

The storage device 250 may be assembled with the central engine 110 inthe housing 101, as shown in FIG. 7, or it may be connected to thecentral engine 110 in a manner similar to an external module (e.g.,module 300). Particularly in the latter case, the storage device 250 mayinterface with a communications interface 210 and connect to the centralengine 110. The interface enables data communications between thestorage device 250 and the central engine 110 and permits themeasurement software 253, or any other software, to be used with centralengine 110. In particular, the storage device 250 has an interfaceelement that is compatible with an interface element 210. In someembodiments, the storage-device interface element physically engages theinterface element 210 to form a serial hardware interface. For example,the storage device 250 may be a USB flash drive, and the storage-deviceinterface element may be a USB connector that is received into a USBport, which acts as the communications interface element 210 for thecentral engine 110.

As a further example, the storage device 250 may be a Secure Digital(SD) memory card with a series of contacts that act as the interfaceelement, and the communication interface 210 may be an expansion slotthat receives the contacts of the memory card. In this example, thecentral engine 110 and the storage device 200 may comply with SDIO(Secure Digital Input Output) interface specifications. It iscontemplated that other memory card formats having different interfacespecifications may be employed. However, having an SDIO is advantageousbecause many hosts such as PDAs, HPCs and smart cellular phones includean expansion slot that is SDIO compatible.

As the central engine 110 in FIG. 7 is filling the role of the computingdevice 370 in the example of FIG. 6, higher-powered processing devicesmay be required. For example, some embodiments may employ handheld orpocket personal computers (HPCs), compatible personal digital assistants(PDAs), or smart cellular phones. As discussed above, these processingdevices may employ a variety of operating systems and configurations.For example, if the computing device 370 is a PDA, the operating systemmay correspond with those of PALM® handhelds from Palm, Inc., orBlackberry® devices from Research in Motion Limited. Advantageously,PALM® handhelds and Blackberry® devices provide a portable device withenough processing power to reliably execute advanced data managementsoftware for results collected from the sensor-receiving module 380.Moreover, such devices provide rich user interfaces that provideadvanced graphical display capabilities. In addition, because thesehandheld devices connect to external networks, such as the Internet, newsoftware or software upgrades/patches can be readily installed.Furthermore, the connection to the telecommunications network enablestest results to be easily transmitted to doctors and other healthcareprofessionals for monitoring or evaluation. Because many consumersalready carry these or similar devices, many users of a diagnosticssystem, such as a diabetes-management system, would convenientlyincorporate the system in devices they already own and carry regularly.

Because embodiments may employ many different types of modules 300 thatmay be situated on different types of hardware, the communicationinterfaces 210 generally have to accommodate more than one type ofcommunication technology, or protocol. However, to minimize the numberof communication interfaces 210 while providing the widest range ofcompatibility between the central engine 110 and the various modules300, the communication interfaces 210 can employ widely-used andstandardized interface technologies, such as USB or Bluetooth®technology. Preferably, the communication interfaces 210 employtechnologies that minimize the amount of configuration required toestablish communication between a module 300 and the central engine 110.Indeed, some communication technologies, such as USB connectivity,provide plug-n-play (PnP) capability. In these embodiments, the module300 is physically connected, for example, through a conventional USBport. Then in response, the central engine 110 immediately recognizesthe module 300 and establishes immediate communication with the module300,

The communication interfaces 210 not only provide communication betweenmodules 300, but they also enable secure communication with externalnetworks. As such, embodiments may employ a connection to an externalnetwork to download updates, upgrades, or additions to the software inthe central engine and/or the modules 300 when the product is out in thefield. In other words, the embodiments may provide field upgradeablesoftware functions. Advantageously, embodiments allow the user to updateany software/firmware in the integrated system, e.g., software for thecentral engine 110 and/or the modules 300, by using program filesprovided by, or purchased from, the manufacturer or an authorized thirdparty. Existing system software can be updated or patched with newerversions, or new software may be added to the system, without requiringthe user to contact the manufacturer or third party for directassistance. The new software allows the user to customize and/or expandthe functionality of the system. In some cases, a product may beessentially converted to a new product. Field upgrades make the latestproduct features available to users who have already purchased aproduct. Moreover, field upgrades making existing product compatiblewith other newly released accessories or devices. For example, in adiabetes-management system, if the BGM 310 uses a test sensor to testblood for blood glucose concentration, and the BGM manufacturer developsa new test sensor that improves accuracy or test time, embodiments wouldallow the user to upgrade the firmware in the device so that the BGM 310is capable of reading the new test sensor.

The central engine may manage aspects of the field upgrade validation incombination with a download engine. The download engine, describedfurther below, can receive system components from a server, e.g., thefield upgrade server, the external network via a communication interfaceand deliver the system components for validation and deployment.Additionally or alternatively, the server on the external network canmanage aspects of the field upgrade process.

In addition, due to the important medical functions associated with themodules 300, embodiments employ validation procedures before employingthe new software or configuration information to ensure that any fieldupgrade does not corrupt the data or the software stored by the productand that the product continues to operate as expected. For example,check-sum routines may be employed to confirm that data or software hasbeen successfully downloaded in its entirety. For example, the centralengine 110 may validate downloads according to an associated data updatefile (DUF) or other component that ensures that the software has beensuccessfully downloaded. For additional data security, the field upgradeprocess may employ data encryption/decryption.

In an example embodiment illustrated in FIG. 9, once a connection isestablished with a field upgrade server in an appropriate externalnetwork (act 502), an available field upgrade is identified for anexisting system component, e.g., new software or configurationinformation, (act 504). The connection to the server may be triggeredautomatically when a connection to the network may be established, or auser may manually initiate communication with the field upgrade server.To identify an available field upgrade, the central engine or the servermay employ a version management program to determine which systemcomponents in the architecture are compatible with, and can be replacedby, newer or different versions stored on the field upgrade server. Thenew system component is then downloaded from the field upgrade server toa memory, i.e., data storage area, that is separate from the memory areastoring the existing system component. An area of memory may bespecifically dedicated for field upgrade operations. In other words, theexisting system component is retained, rather than deleted or writtenover at least until validation is complete. The new system component isvalidated with a system check (act 508), and if the download has beensuccessful and the system operates properly, the new system component isdeployed for regular system operation. Thus, if the field upgrade fails,the previous version of the system component is still available andprovides a recovery or restore option. The new system component isremoved with a failed field upgrade. In some embodiments, the newversion may replace the previous version in memory after the new versionis validated. In other embodiments, the one or more previous versionsare retained even after validation and users may have the option torestore one or more previous versions of a system component if an olderversion is preferred.

An example embodiment is described with reference to FIG. 8. In theembodiment of FIG. 8. the diabetes-management system 400 may includemodules 402, 403, 404, and 405 which collect fluid samples. The digitalengine 406 controls each module, user interface 413, memory 407, and thedownload engine 408. Download engine 408 provides an interface betweenone of the communication modules, digital engine 406, and memory 407.The communications modules may include USB interface 409 which provides,for example, communication between a computing device USB port and thesystem 401. The communication module may also include a Bluetoothinterface 410 which provides wireless communication between the system400 and a computing device, cell phone, and/or other devices capable ofcommunicating with the system 400. Furthermore, a Wi-Fi interface 411provides communication between a wireless network and the system 400.Additionally, the Ethernet interface 411 provides communication betweena local area network and the system 400. Each communication module canbe used to upgrade/update the meter's software in the field upon theuser's direction. The following features may also be downloaded per userrequest: new firmware for new functions; new firmware to update thebehavior of current system functions; user interface language; screenupdates and customization; games and other standalone applications;gauges; and other software or configuration settings/updates.

For example, the user interface may communicate in many languages, butall the data required for those languages does not have to be storedlocally, as users may download language files as required to customizethe operation of their systems. In addition, users can customize theappearance of the user interface display by installing custom picturesto display on the screen or by downloading display layouts madeavailable by a manufacturer or an authorized third party. Furthermore,users can customize the behavior of the system by installing standaloneapplications (such as games) that can run on the system processor and beplayed when the system 400 is not being used to analyze body fluids.Users can also customize system behavior by installing software thatchanges the way body fluid analysis results are displayed, as resultsmay be presented as digital readouts, simulated analog gauges,qualitative feedback, etc.

Referring again to FIG. 4, the input/output interfaces 200 also includeuser interfaces 220, which generally allow the modules 300 to displayinformation, such as test results, to the user. The modules 300 maytransmit such information to the central engine 110 via communicationinterfaces 210, and the central engine 110 may in turn present theinformation on the display interfaces 220. Although centralized handlingof communications may be preferred, the modules 300, in some cases, mayinterface directly with the display interfaces 220. As shown in FIG. 2,the display interfaces may include graphic liquid crystal display (LCD)or organic light-emitting diode (OLED), segment LCD or OLED, MP4playback, or the like.

In addition, the input/output interfaces 200 may allow information to becommunicated to and from the user via audio signals. For example, theinput/output interfaces 200 may include a speech synthesizer, MP3playback, or the like, for communicating audio information to a user.Additionally, the input/output interfaces 200 may also include a speechrecognition mechanism to receive audio information from a user.

Furthermore, the user interfaces 200 may allow the user to inputinformation or instructions into the system. For example, the user maybe required to respond to simple prompts or make menu selections toguide one of the modules 300 during operation. Or as a further example,the user may want to enter instructions to retrieve information, such astest results, and to present the information on the display interfaces220. Mechanisms for providing input, for example, may include a keypad,a touch screen, a thumb wheel, or the like.

As shown in FIG. 7, a user interface 115 may be incorporated into thehousing 101 in which the central engine 110 and correspondingcommunication interfaces 210 are assembled. As such, the housing 101 mayform a portable device 101 for a health monitoring and delivery system.As discussed previously with reference to FIG. 3, some modules 300, suchas the BGM 310, may be incorporated into the device, while othermodules, such as CGM 320 and the insulin delivery module 330, may beexternally connected to the portable device 101 through thecommunication interfaces 210. The modules 300 connected to the digitalengine 310 have access to the interface

Systems employing the architecture support various types of electronicnetworks and communications. Modules 300 may be employed, for example,to provide cellular activity. Other embodiments, alternatively oradditionally, may employ global positioning system (GPS) technology,which has become widely accessible to civilian applications such as roadnavigation, people tracking, and timing services. With the technologybecoming more and more mature, the cost of integrating this technologyinto consumer products and medical device has been significantlyreduced. GPS receiver chipsets are currently available on market and canbe easily integrated with consumer or medical device to provideinformation on device location, velocity and Universal time. As such,GPS may be provided to enhance the functionality of a system employingarchitecture to form an integrated system for monitoring a healthcondition and/or delivering a medication.

With GPS, a diabetes-management system, for example, can provideadditional information associated with glucose tests. Accuratetimestamps and locations can be associated with readings. The erroneoustimestamps generated by conventional meters have been the source ofconfusion and difficulty when readings from multiple meters aredownloaded and merged into one database file, or uploaded to computersor web servers that do not have their local time in sync with themeters. Patient movement and exercise can be tracked automatically,facilitating patient logging effort tremendously. The data may includedistance and speed. This information can be used for patient dailyactivity planning for exercise, diet, medication and blood glucose testfrequency, etc. It also enables comprehensive analysis of correlationbetween reading patterns and daily activities Furthermore, patients canbe located in emergencies.

The additional timing, location and physical activity informationobtained with GPS, combined with logged diet, medication information,can assist the diabetes-management system to make more accuratepredictions on patients' daily blood glucose patterns. Thediabetes-management system can make real-time daily activityrecommendations that will help them to control their blood glucoselevels in the prescribed range. The system can then remind patients totake the right number of tests daily at the right moments.

Accordingly, GPS may be employed to synchronize a system's device's realtime clock (RTC) to UMT with high precision so that glucose readings canbe associated with correct timestamp. As power for the GPS functionalitymay be a consideration, the GPS receiver may only need to be activatedonce a day or a week depending on the device crystal quality. Assumingthat each time the GPS consumes 0.175 mAhr power (calculated based onXemics XE1600 receiver using Trimble chipsets), and the device takes aGPS measurement once a day, 63.9 mAhr is consumed in a year for the GPSrelated calculation which is roughly about 10-20% of a regular cellphone battery capacity.

As discussed previously, some portable embodiments of an integratedmonitoring/delivery system may connect with a computing device 370 foradvanced data management. This situation provides the opportunity forapplying the NAVSYS GPS recorder model (TrackTag) to the portable deviceto track patient movement and activity. Because a GPS recorder simplytakes snapshots of satellite signals without processing them, asignificant amount of power can be saved. Assume the device takes a GPSsnapshot once every 150 sec, then in one year this GPS recorder onlyconsumes about 280 mAhr, which is roughly about <50% of a regular cellphone battery capacity. If the device can stop taking snapshots at nightthen further energy can be preserved. The trade off in using theTrackTag approach is the required amount of on-device memory required.Every snapshot takes about 15 kbyte, so at the above snapshot rate,there will be about 200,000 snapshot per year which requires about 3Gbyte memory. Of course, once GPS data is downloaded from the device tocomputer and processed, the device memory can be freed up and reused. Itseems that one Gbyte memory may support 4 months of location trackingfor the portable device. Using modern flash memory technology, one Gbytedevice memory can be easily accommodated.

The GPS functionality may be a built-in central function. In a moremodular example, however, the GPS functionality may be provided by aconnected module, i.e. a detachable GPS receiver. Indeed, if the GPSreceiver module has its own memory to store time and positioninformation, then the GPS may not need to be connected all the time withthe DM device. The GPS receiver may be connected with the system once aday or one every few days depending on how often the device clock needsto be synchronized and also on the availability of GPS receiver memory.Advantageously, the use of a detachable GPS receiver module minimizedthe impact on hardware/software design of the central engine 110 andother aspects of the system. Moreover, power management is facilitated.

While the invention is susceptible to various modifications andalternative forms, specific embodiments and methods thereof have beenshown by way of example in the drawings and are described in detailherein. It should be understood, however, that it is not intended tolimit the invention to the particular forms or methods disclosed, but,to the contrary, the intention is to cover all modifications,equivalents and alternatives falling within the spirit and scope of theinvention.

1. A system for managing healthcare data, comprising: a first set of at least one module providing primary healthcare functions; a first central engine controlling the first set of at least one module; a second set of at least one module providing secondary healthcare functions; a second central engine controlling the second set of at least one module; and a communication interface providing a connection between the first central engine and the second central engine.
 2. The system of claim 1, wherein the first central engine is assembled with the first set of at least one module according to a first development process and the second central engine is assembled with the second set of at least one module according to a second development process.
 3. The system of claim 1, wherein the communication interface is at least one of a USB interface, a radio frequency (RF) interface, a Wi-Fi interface, and an Ethernet interface.
 4. The system of claim 1, wherein the first central engine is implemented on a first mother board, the second central engine is implemented on a second mother board, the first set of at least one module is separately implemented on a first set of at least one daughter board, and the second set of at least one module is separately implemented on a second set of at least one daughter board.
 5. The system of claim 1, further comprising a first housing including the first central engine and a second housing including the second central engine.
 6. The system of claim 1, wherein the first set of at least one module provide a diabetes-management system.
 7. A method for managing healthcare data, comprising: developing, according to a first development process, a first assembly of a first central engine and a first set of at least one module providing primary healthcare functions, the first central engine controlling the first set of at least one module; developing, according to a second development process, a second assembly of a second central engine and a second set of at least one module secondary healthcare functions; and connecting the first assembly and the second assembly via a communication interface. 